home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 12⁄31⁄89 / 0280-view initialization-Dec89 < prev    next >
Encoding:
Text File  |  1990-01-02  |  2.6 KB  |  68 lines  |  [TEXT/GEOL]
  1. Item    2213468                         28-Dec-89        17:56
  2.  
  3. From:   D1282                           Power Up,PRT
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. Sub:    view initialization
  8.  
  9. Attn:  MacApp.Tech$
  10. SentBy: James Plamondon
  11. Date   12/28/89
  12. Subject    view initialization
  13. From   James Plamondon
  14. To  MacApp.Tech$
  15.  
  16. Subject:   view initialization
  17. Gentlepersons,
  18.  
  19. A couple of weeks ago I suggested that a new set of routines,
  20. InitTemplateWindow(), DoInitView(), and InitAView(), be added to MacApp to
  21. support the reinitialization of views from their view resources.  The general
  22. response was that  a) it was going to be too hard to implement to be worth it,
  23. especially when…  b) it was not a mainstream feature, so that…  c) if I really
  24. wanted to do it, I should do it via subclassing, rather than by changing
  25. MacApp.
  26.  
  27. I've come across another example of how the distinction between view creation
  28. and view initialization is useful (even essential) which I would like to
  29. present for your consideration.
  30.  
  31. If a view needs to contain an explicit reference to another view, the
  32. reference often cannot be initialized during IRes(), because the view being
  33. referenced may not have been created yet.  Only those views preceding a given
  34. view in an in-order traversal of the view hierarchy have been created when
  35. IRes() is called on the given view.  A call to FindSubView() will fail if the
  36. view being sought has not yet been created.
  37.  
  38. If the distinction between creation and initialization were made, this would
  39. not be a problem.  First, the tree would be traversed, creating all of the
  40. specified views.  Once all were created, then the tree would be traversed
  41. again, allowing each specified view to initialize itself.  Since all of the
  42. views in the hierarchy would exist during the initialization phase, all calls
  43. to FindSubView() would work properly.
  44.  
  45. I’ve encountered this problem repeatedly in MacApp.  My usual solution is to
  46. have the subview initialize its parent’s reference to the subview during the
  47. subview’s IRes() method, but this is a clear violation of the principles of
  48. data abstraction, OOP, and motherhood itself.
  49.  
  50. I admit that the distinction between object creation and object initialization
  51. is not obvious, nor has it been discussed in the OOP literature, so far as I
  52. can tell.  Perhaps I am making a mountain out of a mole-hill — but I would
  53. like to hear the comments of anyone interested, pro or con.
  54.  
  55. Looking forward to your responses, I am
  56.  
  57.  
  58. Yours,
  59.  
  60. James Plamondon
  61. Software Engineer
  62. PowerUp! Software
  63. 2929 Campus Drive, Suite 300
  64. San Mateo, CA  94403
  65. (415) 345-5900 x351
  66. AppleLink: PowerUp.Eng
  67.  
  68.